In communication systems, for example mobile radio networks according to the GSM (Global System for Mobile Communication) or UMTS (Universal Mobile Telecommunication System) standard, connections between two stations or network elements that are located at a distance from each other are generally set up via a plurality of further network elements, so that the two end stations can communicate with each other.
The session initiation protocol SIP is known for signaling connections (sessions) between in particular mobile users or stations and this describes a protocol and a network infrastructure. According to this, SIP messages are routed from a source user or a first station generally via a plurality of signaling servers to a second station as the destination user. In order to be able to provide extended communication services, such as for example session forwarding, number translation, pre-paid, etc. in such a signaling environment, different approaches are under discussion, such as call processing language CPL, SIP servlets (SIP-Java programming interface), SIP CGI (common gateway interface/general SIP access interface). A service thereby generally comprises a service logic in the form of a program code and status information in the form of data. In the case of personalized services, said status information is station-specific or user-specific. When forwarding messages, the signaling servers run the service logic or execute its instructions, whereby status information is included. In this way the service logic can influence the response of the signaling server.
In such an environment problems arise due to the possibilities for distributing the service logic and status information. If a new service is launched, this information must be made available to the signaling servers involved in the running process. An obvious approach would be to install said information in a permanent manner for administrative purposes on a specific signaling server. In the case of personalized services, this would however require a user or their station always to use the same signaling server. This assumption is not practical for the following reasons:    a) in mobile radio networks users or their stations are generally mobile and can only or have to use a signaling server in their proximity, located for example in a local intranet, in a dynamic manner.    b) A signaling server may break down, whereupon the user or their station must be able to use an alternative server. The information would also have to be installed on such a server to be made additionally available.    c) A load distribution method can generally be used in mobile radio networks, to assign users or their stations to the signaling server with the smallest load out of a plurality of signaling servers.
This possibility would also not be applicable or would require the information to be installed on the plurality of signaling servers.
These problems occur in particular in systems, as for example with the multimedia subsystem architecture defined by 3GPP (3rd Generation Partnership Project), according to which a signaling server from a plurality of available signaling servers is allocated to a user-side station in a dynamic manner during the registration process.
IETF proposals from the internet field (IETF: Internet Engineering Task Force), such as Java Enhanced SIP (JES) and servlet delivery (SDLI), describe methods, by means of which service logic and status information can be transported together with signaling messages. Stations or terminals “append” the service logic to messages, whereby the signaling servers extract said information and run the service logic as required. However such approaches do not resolve the above problem satisfactorily:    d) In a mobile network environment the bandwidth of the air interface is a valuable resource. It would be a waste of this resource, if a large amount of service logic and status information were transmitted from the stations into the network.    e) For security reasons many network operators also have serious misgivings about receiving and running just any service logic from user-side stations. This could have an adverse effect on the stability of the network.    f) Also status information changes, which may result from the running of a service, cannot be stored permanently. This would be necessary however, if this changed status information were required for the repeat running of a service.    g) It should be possible to run many services without involving an end station, e.g. call forwarding when the station is not available.